IBIS Macromodel Task Group Meeting date: 08 March 2022 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Jared James Google: Zhiping Yang Intel: * Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao Majid Ahadi Dolatsara * Ming Yan Radek Biernacki Rui Yang Luminous Computing David Banas Marvell Steve Parker Mathworks (SiSoft): * Walter Katz Mike LaBonte Micron Technology: * Randy Wolff * Justin Butterfield Missouri S&T Chulsoon Hwang Siemens EDA (Mentor): * Arpad Muranyi Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Fangyi to propose language changes for PAM_Thresholds Usage Rules in BIRD213.1. - Done. Arpad has sent out a draft 15 incorporating Fangyi's language. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the March 1st meeting. Michael moved to approve the minutes. Ambrish seconded the motion. There were no objections. ------------- New Discussion: BIRD213.1 draft 15, PAMn: Arpad shared draft 15 and reviewed Fangyi's language changes. Fangyi had noted an inconsistency, in the Usage Rules for PAM_Thresholds, in the language used to describe the location of the "eyes". The second paragraph of the section described the progression of eyes: "The eye with the lowest threshold voltage is eye "1", the eye with the next threshold voltage up is eye "2", ..." In the bulleted list that followed, however, the definitions of the voltage ranges corresponding to symbol values referred to rows in the PAM_Thresholds Table. That is, eye 1 corresponds to the value in row 1 of the PAM_Thresholds parameter, eye 2 corresponds to row 2, etc. Fangyi's new language in the second paragraph associated eyes with rows in the Table instead of referring to the magnitude of the threshold voltages (e.g., row 1 instead of "lowest threshold voltage" corresponds to eye 1). No one objected to these changes, which made the paragraph consistent with the bulleted list that followed. Fangyi noted that this language allowed the possibility of the model returning threshold voltages that were out-of-order (not monotonically increasing with row). Randy noted several places in the BIRD where "Row" was capitalized and should not have been, and Arpad changed them to "row". Fangyi said that based on a suggestion from Curtis he thought we should change any instances of "symbol value" (e.g., in the Usage Rules: for PAM_Thresholds) to "symbol voltage". Curtis had asked if we should avoid use of "detected as symbol value N", since we are trying to keep IBIS out of any involvement in mapping. Curtis had suggested replacing "symbol value" with "voltage level". Fangyi agreed with the idea of replacing "symbol value", but he suggested replacing it with "symbol level". Fangyi said "symbol level" better captured the concept of discrete symbol levels, while "voltage level" implied a continuum. Curtis agreed with Fangyi's "symbol level" suggestion. No one in the group objected to the change, and Arpad replaced instances of "symbol value" with "symbol level". The group resumed the previous week's discussion of Table vs. String for the PAM_Thresholds and PAM_Offsets parameters. Curtis recalled that some attendees had expressed concern about the difficulty in defining the contents of the parameters if we instead used Type String, and some discussion had suggested there were significant differences in what the model returned in the case of String vs. Table. Curtis said he had gone back to review IBIS 7.1 and what the contents of the parameters_out string returned by the model would be. In fact, since a multi-row Table is collapsed to a single sequence of values when passed in or out of a model, the contents of the parameters_out string returned by the model were almost identical. For example, a PAM4 case was shown: With a String parameter as proposed by Ambrish, the format of the PAM_Thresholds portion of the parameters_out string would be: (PAM_Thresholds "-0.333 0.0 0.333") With the Table parameter, the format of the PAM_Thresholds portion of the parameters_out string would be: (PAM_Thresholds -0.333 0.0 0.333) The returned values are identical, except for the surrounding quotes. Since they are almost identical, and the String parameter is simpler overall, Curtis said he was further inclined to support Ambrish's motion (which had been withdrawn) to use a String parameter instead of a Table. Ambrish said he thought a Table was overkill in this application and offered no advantages. He said he thought it was simpler in the .ami file, for the model maker, and in the language in the specification to use String parameters for PAM_Thresholds and PAM_Offsets. Walter said he had come around to agree with Ambrish. Bob said all the points about simplicity were well taken. He said one concern he had was that the existing PAM4_UpperThreshold, PAM4_CenterThreshold, and PAM4_LowerThreshold were Floats, and now we would be using a String Type for the new parameters. Ambrish and Curtis agreed, but they noted that the existing PAM4 threshold parameters used a separate parameter for each threshold, and the new PAM parameters would be returning multiple values whether a Table or String parameter were used. Arpad asked if we had agreement to use String instead. Ambrish moved to use String parameters instead of Tables for PAM_Thresholds and PAM_Offsets. Walter seconded. There were no objections. Arpad said he would send the current draft with today's changes to the ATM list as draft 16. Ambrish took an AR to make the changes necessary to switch from Tables to Strings. Bob noted that one other difference with the existing PAM4 threshold parameters was that they are not just Usage Out as the new PAM parameters are. Walter agreed. AMI Parameter tree root name clarifications BIRD draft: Michael reviewed comments Arpad had sent to the ATM list in response to draft 3. Arpad had asked if: "This root name shall be compared to the built-in root name of the receiving algorithmic model." should be (change "of" to "by"): "This root name shall be compared to the built-in root name by the receiving algorithmic model." Michael said this was a good question and raised the issue of directionality. He added language explicitly stating that the value passed in via parameters_in is checked by the model, and the value the model returns through parameters_out is checked by the EDA tool. Arpad's next question had been, "What should the model do if it finds a mismatch?" Michael said we could mandate that the model must return zero (the return value of the called function) if it detects a mismatch. Arpad said his question had been more about whether detecting a mismatch was a reason for the model to fail. Michael suggested that he thought it should not be a reason to force the model to fail. He said this had been discussed at length in the Quality task group. He said you might have the option of AMI tree selectors, and root names might be a way of selecting between them. He said we might not want to legislate that flexibility out of existence. Arpad noted that the directionality BIRD that had added Executable_Tx and Executable_Rx allowed the possibility of a dual executable model that worked with Tx and Rx .ami files. Arpad asked if we wanted to obligate the model to return an error on mismatches. Curtis agreed, and he asked if we should change any language referring to models checking the value of root name against their internal root name to allow the possibility of a single executable model accepting multiple root names (plural). Michael said the Tx and Rx direction .ami files could each use the same root name. Arpad said more discussion on this topic was needed. Michael said he would send out draft 4. - Ambrish: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Arpad to send draft 16 of BIRD213.1 to the ATM list. AR: Ambrish to add Table -> String changes to draft 16. AR: Michael to send draft 4 of the Root Name Clarifications BIRD to ATM. ------------- Next meeting: 15 March 2022 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives